COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂28-Feb-77  1204	FTP:LEFAIVRE at RUTGERS-10	NEWEST COMPILER   
C00004 00003	∂15-Mar-77  1913	FTP:LEFAIVRE at RUTGERS-10	YET ANOTHER COMPILER BUG    
C00008 00004	∂05-Nov-77  0624	FTP:LEFAIVRE at RUTGERS-10 	YET ANOTHER COMPILER BUG   
C00012 ENDMK
C⊗;
∂28-Feb-77  1204	FTP:LEFAIVRE at RUTGERS-10	NEWEST COMPILER   
Date: 28 Feb 1977 (Monday) 1503-Est
From: LEFAIVRE at RUTGERS-10
Subject: NEWEST COMPILER
To:   DIFFIE at SU-AI

Whit-

I recently found another obscure bug in the compiler, making the version
you have obsolete already (!).  The corrected version is in LSP:ILISPC.LSP.
Note that I have finally released the entire RUTGERS/UCI LISP system,
including ILISP itself (with the new prettyprinter, lots of new functions,
↑C interrupt routine, etc.), ILISPC (with bug fixes, in-line ERRSETs, etc.),
and ILISP versions of PLNR, FUZZY, and CNVR (CNVR not quite ready yet).
All of the new stuff (including new features of the compiler) is described in
LSP:ILISP.MAN, which should magically appear in about an hour (I am making
some final editing changes).  I don't know if you have a locally-hacked
UCI LISP out there or what, but you might want to look at RUTGERS/UCI LISP
for use at Stanford.  If you do, send me a tape and I'll copy the LSP:
library onto it.

-Rick

∂15-Mar-77  1913	FTP:LEFAIVRE at RUTGERS-10	YET ANOTHER COMPILER BUG    
Date: 15 Mar 1977 (Tuesday) 2214-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

My new version of the compiler is now affectionately (?) known at
Rutgers as the "BUGLESS COMPILER" because of the assurances I keep
giving people that I've finally (underlined) found the LAST BUG!
Well, another one turned up last weekend.  Its good that the system
is now officially released, as more people are giving it a workout.
Following this message is a new version of the compiler, followed
by an updated CTEST (the latest bug is RB9).  I think it's easier
to just send the whole thing over this way instead of sending the
changes and having you incorporate them in your version.

-Rick

∂28-Jul-77  1752	FTP:LEFAIVRE at RUTGERS-10	Another ILISPC bug bites the dust
Date: 28 Jul 1977 (Thursday) 2050-Est
From: LEFAIVRE at RUTGERS-10
Subject: Another ILISPC bug bites the dust
To:   DIFFIE at SU-AI

Whit-

Just discovered another bug in the compiler I sent you a while ago.  As
this one was of my own doing, I feel especially obligated to let you know
about it.  It came about because I moved the old GUARDLOCS code and the
CLEAR1 inside of P2COND1, so it could be called both by P2COND and BOOLCOND.
In so doing, I inadvertantly masked out P2PROG's copy of MINDEPTH, so that
if a CLRPVARS is delayed until after a COND is entered, it is possible for
the stack to be popped too far.  This bug has been in for about a year, and
it only made itself known today, so it is rather rare.  My fix was to split
P2COND1 into two PROGs, with the second binding MINDEPTH after the CLEAR1 is
done in the first.

We also discovered that if a special var has the same name as a function
and it is called before the function is defined or declared, the call is
compiled as a variable (as one would expect).  However, the user is not
warned about this when the function is finally defined.  I put a check in
for this, along with a couple of other little fixes.

If you still have plans to use this compiler, I will be happy to FTP it
over (or send me a tape and you can have the whole super RUTGERS/UCI LISP
system - it's now spreading to other TOPS installations around the country).

-Rick

∂05-Nov-77  0624	FTP:LEFAIVRE at RUTGERS-10 	YET ANOTHER COMPILER BUG   
Date:  5 Nov 1977 (Saturday) 0921-Est
From: LEFAIVRE at RUTGERS-10
Subject: YET ANOTHER COMPILER BUG
To:   DIFFIE at SU-AI

Whit-

Cris Perdue at CMU uncovered another bug in the LISP compiler.  The simplest
manisfestation seems to be a function like:

	(DE TST (X) (FUNC (CAR X) (FUNC2 (CAR (CAR X)))))

The problem is that when CSTEP goes to load the first CAR, COPT tells it
that it is equivalent to the second and needn't be recomputed.  This
association is established via VARLIST.  But when CSFUN is called to
clear the first CAR off of CCLST, it calls ILOC instead of ILOC1, and
ILOC doesn't check VARLIST, so another call to LOADCARCDR is made.
Since the second CAR has already been loaded and REMOVEd, LOADCARCDR
decides it must reload the CAR, but X is long gone and . . . BANG.

I don't know if this bug has been around for awhile or not.  None of
my fixes affected this stuff directly, but some other fix might have
impacted on it.  Anyway, the fix appears to be to change CSFUN to call
ILOC1 instead of ILOC:

	(DFUNC (CSFUN L AC)
	 (PROG (Y) (AND (SETQ Y (ASSOC (CAR L) LDLST)) (ILOC1 Y AC))))

(The LOADCARCDR in CSFUN is now done by ILOC1 if necessary).

I've also decided to fix a problem with the in-line MAP functions.  The
interpreter takes the CDR BEFORE it applies the function, so if the
function does a RPLACD things are ok.  The compiled code tries to take
the CDR AFTER the function application, so a RPLACD screws things up.
I'm going to fix the compiler to do it the way the interpreter does.
While I'm at it I'm going to change MAPCAR, MAPLIST, MAPCONC, and
MAPCON to use TCONC and LCONC instead of doing it all in-line - should
save some space.

There is a growing effort to try and standardize Stanford/UCI/Rutgers
LISP as the major LISP after INTERLISP and MACLISP, headed by Jim
Meehan at UCI, Cris Perdue at CMU, and myself.  We are discussing
such controversial topics as just what should be in the system and what
should be in library packages, and how we can work jointly on a comprehensive
manual.  Would you (or someone else there) have any interest in joining
such an effort?